SPACE SHUTTLE 


ORBITER AVIONICS SOFTWARE 
NAS 9-14444- 


NASA CR- 


n^ft-CK-141745) I OP KODELIMG STUDY Final 
(NRSA-UK i /*•-»# . • ns ss Hachmes 

Report (International Busxn CSCL 22A 

Corp.) - 6 P HC $3.2 5 


G3/13 _ 


N75-21319 


Unclas 

19245 




IOP MODELING STUDY 

% 

FINAL REPORT 



IBM FEDERAL SYSTEMS DIVISION 
1322 Space Park Drive 
Houston, TX 77058 


75-SS-0582 


3/26/75 



Objectives 


The objectives of this study were to develop a more de- 
tailed model of the IOP, and to use the model to evaluate IOP 
performance and its effect on Flight Software performance. These 
objectives have now been accomplished.. 


Results & Recommendations 

The current design of the MSC control program, FIOMCNTL, 
yields an I/O request service time much longer than was previously 
assumed. The longer service time causes an increase in the GN&C 
Flight Control transport lag to an average of 14.3 ms and maximum 
of 16.9 ms; further, the variability of the service time causes 
an increase in the critical input sampling jitter (see Reference 1) 

Several modifications to FIOMCNTL were tested in the model, 
each of which reduced the average service time for I/O requests.. 
The best case studied would have reduced the transport lag to 
about 13 ms average, but the worst case would still have occasion- 
ally exceeded 15 ms. A redesign of FIOMCNTL therefore appears 
necessary and is recommended by Systems Analysis. 

DMA response time was not a ^serious problem in the model 
runs which were made. Average DMA response was 4. 4 g sec, the 
maximum number of requests outstanding was 7, and the average 
number outstanding was less than one. 


Findings 

The detailed IOP model developed for this task simulates 
the execution of every MSC and BCE instruction. By defining 
-the ‘MSC control program, FIOMCNTL, and the BCE programs to read 
and write data, the operation of the IOP in a realistic environ- 
ment was simulated. The I/O load used to drive the IOP was the 
profile developed for the Approach and Landing phase of the ALT 
mission, (see References 1 and 2) . 

A breakdown of an application's request for I/O is shown 
in Figure 1. Times 1-6 in Figure 1 occur within the IOP, and. 
the primary output of this study is the length of these times 
for the basic FIOMCNTL program and two other cases with modi- 
fications to that program. The primary difference in the three 
cases was the length of time required for the MSC to recognize 
a request completion (time 5 in Figure 1) . The three cases are 
defined as follows: 



Figure- 1 
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A. FCOS Starts Request 

1. Time From FCOS Readying The Request 
Until MSC Starts On Request.. 

2. MSC Set Up Time 

3. BCE Set Up Time 


4. BCE Clean-Up Time 

5. MSC Recognition Of BCE Completion 

6. MSC Clean-Up Time 

B. FCOS Services Of I/O Interrupt And 
Dispatching Of Task If It Waited. 
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Case 1 - Basic FIOMCNTL. This case assumes that any BCE 
may be the low BCE in an outstanding request. Therefore, when 
monitoring for completion of requests, the MSC must step sequen- 
tially through all 24 entries (one per BCE) in a 'BCE completion' 
table. The. MSC checks each entry to see if a request is out- 
standing; if it finds an outstanding request, the MSC issues a 
Repeat until All Indicators (RAI) instruction for the BCE ' s in- 
volved in the request. This instruction will delay for up to 
lOOysec? if all BCE's are complete before this time is up, the 
MSC performs clean-up operations on the request and signals the 
CPU. When either timeout has occurred or clean-up operations have 
been done , the MSC increments to the next entry in the table and 
checks for an outstanding request. As long as there are any active 
requests, the MSC continues to loop through this table; if a new 
request comes in from the CPU, the MSC will branch. to start that 
request (time 2 in Figure 1) and return to continue monitoring 
for completions. 

Case 2 - Basic FIOMCNTL modified to check only those table 
entries for which a BCE is active. This case is the same as 
Case 1 with the exception that, by using the CPU’s table of reserved 
BCE's, the MSC is able to skip those 'BCE completion table' entries 
for which the CPU has not initiated a request. Since some requests 
use multiple BCE's, however, the MSC is still checking superfluous 
table entries. This case was used ih the ALT PDR Analysis to yield 
a 14.3 ms transport lag (Ref. 1). 

Case 3 - Basic FIOMCNTL modified to check only those table 
entries corresponding to the low BCE of an active request. This 
case is a further improvement over Cases 1 and 2. It assumes that 
the CPU will maintain a word with bits set for only those BCE's 
which are the lowest BCE of an active request, thereby permitting 
the MSC to eliminate all unnecessary checking of 'BCE completion 
table' entries. 

Table 1 summarizes the results of the three cases. It 
shows values of times 1-6 in Figure 1 for each case, as well as 
the minimum, average, and maximum response times for I/O requests. 
The only difference in the three cases is in the average and maxi- 
mum values for time 5, MSC recognition of BCE completion. Average 
DMA response time was the same in all three cases (4.4psec). 


Fu ture Plans 

FCOS developers are currently studying alternative designs 
of the MSC control program to reduce both the request service 
time and the variability in that time. Systems Analysis' modeling 
support will be provided to evaluate the alternative designs. 
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Table 1 


Summary of I/O Service Times within the IOP 


Time Segment (From Fiq. 1) 

Case 1 

~T 

Case 2 

Case 3 

1 - 

MSC Recognize new Request 

Average 

305m sec, Range 0-800Msec 

2 - 

MSC Set up and Start BCE's 

[92+ (64*No . of BCE ' s) + ( 4*Low BCE ID) ] 
*16.5 

8 P sec 


Request for BCE #10 



4Q4visec 


Request for BCE's 10-13 



800m sec 

3 - 

BCE Set up Time 

165Msec (repeat for each program if 
chaining) 

4 - 

BCE Clean up Time 

66m sec (at end of last program only, 
if chaining) 



Average 
32 6 0M sec 

Average 
2100 m see 

Average 
1280m sec 

5 - 

MSC Recognize BCE's 
Complete 

Ran^e 

0-6200u 

sec 

Range 
0-4100m sec 

Range 

0-285 0m sec 

6 - 

MSC Clean-up of Request 

1 112+ ( 51*No . of BCE’s 
*16.5 
— § — M sec 

) + ( 4 *Low BCE ID) ] 


Request for BCE #10 



419Msec 


Request for BCE's 10-13 



734 Msec 

Elapsed time for a Request 
within the IOP (exclude data 
Sfer) 





a . 

,1 BCE, no chaining 

. 

■ 





Min 

1.05 ms 


1.05 ms 

1.05 ms 


Avg 

. 

4.60 ms 


3.45 ms 

2.65 ms 


Max 

8.05 ms 


5.95 ms 

"4.70ms 

b. 

4 BCE's, no chaining 






Min 

1.75 ms 


1.75 ms 

1.75 ms 


Avg 

5.30 ms 


4.15 ms 

3.35 ms 


Max 

8,75 ms 


6.65 ms 

5.40 ms ! 
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